Generally, wireless communication networks suffer a disadvantage in comparison with wired communication networks because wireless communication networks must utilize valuable radio frequency spectrum for the transmission of signals to wireless mobile devices (including portable terminals such as computer terminals or personal communication devices). Licensed spectrum is expensive to purchase as exemplified by the wireless communications RF spectrum sales of the 1990's. Moreover, the greater the application of uncompressed signals, power for transmitting signals in the purchased RF spectrum can be wasted along with the spectrum utilization increase. Further complicating and making the need for compression even greater in a wireless communication network, the applications for such mobile devices have greatly expanded as wireless communications have, in many instances, replaced wired communication devices because of the great, almost unbounded popularity of the devices and the features that such devices may provide.
Consider, for example, currently available mobile devices providing input/output for taking and receiving digital photographs (which can be compressed in accordance with known JPEG compression techniques), receiving downloaded MPEG compressed movie streams for a subscriber's viewing pleasure, the opportunity to short text message to “buddy lists” of friends, associates and family members having mobile devices, download, store and play compressed digital music in stereo of the subscriber's choice and so on.
Also consider the differences between text compression, for example, the compression of a voice message converted to text or a text document or a text message versus JPEG or MPEG compression. The former needs to be lossless, that is, the message at the transmitter ideally should be perfectly reproduced at the receiver after compression and decompression. On the other hand, JPEG and MPEG image compression follow a different philosophy. The compression/decompression process does not need to be perfect. Some original image data may be intentionally lost but only such that the received image is practically identical to the transmitted image and any loss is not perceptible to the viewer.
In a virtual machine, bytecodes are known for representing the machine language of, for example, a Java virtual machine. The bytecode stream represents a sequence of instructions for the virtual machine. Besides bytecode compression, the hypertext transfer protocol (HTTP) is a candidate for compression. HTTP is a known protocol for internet address and command processing. In wireless communications involving the network, there is a need for compression of such data signals. These types of data streams are akin to text compression where there is a requirement for lossless compression/decompression processes.
Many of the new applications for mobile devices have centered around an implementation of a session initiation protocol (SIP) described, for example, by RFC 3261. SIP provides a protocol for negotiating session parameters between session endpoints, for example, such as setting up and tearing down Voice over IP sessions between VoIP phones or sessions in which a camera image is transmitted from one cell phone to another. Moreover, data signal transmission and data compression are also known from such well known compression algorithms as ZLIB (RFC 1950), DEFLATE (RFC 1951) and GZIP (RFC 1952), and other compression algorithms and techniques, all of which are well known to the Internet community at large.
More recently, progress has been made in the development of standard compression interfaces and techniques for signal compression as exemplified by the efforts described by RFC 3320 and RFC 3321. Also, recently, a session initiation protocol (SIP) and a session description protocol (SDP) static dictionary has been described in RFC 3485. Moreover, a so-called universal decompressor virtual machine (UDVM) is described, for example, in RFC 3320, much like a Java virtual machine, for running decompression algorithms and to provide almost unlimited flexibility for choosing how to compress/decompress a given item of data. With UDVM, both terminal ends, referred to as endpoints, for example, two mobile devices exchanging photographs or a mobile device gaining access to a video-on-demand movie server, must execute a decompression bytecode that is compatible with the compression algorithm employed at the other end for the data signal; otherwise, decompression will fail to reproduce the original signal. Moreover, successful use of a given bytecode may require that one or more static dictionaries be available to the UDVM that executes the bytecode. Bytecode is defined in RFC 3320 as machine code that can be executed by a virtual machine such as a UDVM. An endpoint is defined as one instance of an application, a SigComp layer, and a transport layer for sending and receiving SigComp messages.
An example of an endpoint according to RFC 3320 is shown in FIG. 1 taken from RFC 3320 but further including UDVM memory 131. An endpoint as defined above may include a compressor dispatcher 110 and a decompressor dispatcher 115, a UDVM decompressor 130 and an associated memory 131, a state handler 135 and compressors 1 120 and 2 125 operating between an application layer 105 and a transport layer 140. Bytecode for running UDVM 130 is typically stored in memory 131 comprising UDVM registers (not shown). A UDVM memory may be a maximum 65536 bytes.
Section 7 of RFC 3320 defines a SigComp message format, for example, as per FIG. 2 and is taken from FIG. 3 of RFC 3320 but is modified according to one embodiment of one inventive aspect for permitting an efficient loading of bytecode. Section 7.3 particularly describes a process of uploading UDVM bytecode to the UDVM 130 of an endpoint of FIG. 1. Moreover, RFC 3320 suggests where bytecode should be installed in UDVM memory 131. However, the bytecode is presently limited to a maximum size of 4095 bytes.
A typical UDVM instruction set comprises 36 instructions, of which certain instructions have associated operands. To reduce the size of typical UDVM bytecode, RFC 3320 suggests that operands for a UDVM instruction be compressed using variable-length encoding, the aim being to store more common operand values using fewer bytes than more rarely occurring values. Also, RFC 3320, section 3.3.3 suggests that an endpoint may offer “well-known decompression algorithms, dictionaries of common phrases used in a specific signaling protocol” and the like.
A state is defined by RFC 3320 as data saved for retrieval by later SigComp messages. If a given state item is already locally available at a decompressing UDVM 130 of the endpoint of FIG. 1, it need not be uploaded to the endpoint. While RFC 3320 suggests that well known decompression algorithms can be utilized at endpoints per FIG. 1 as locally available state items, RFC 3320 fails to specify where in UDVM memory locally available bytecode as a state item should be placed. Although RFC 3320 states that endpoints “can indicate their interest in receiving a list” of state items that are locally available at the far end, RFC 3320 does not specify actions to take upon learning that a desired state item is not available. In particular, RFC 3320 does not offer a means for an endpoint to update its collection of bytecodes and/or static dictionaries for the benefit of subsequent SigComp usage.
On the other hand, in SigComp as applied in SIP, headers as well as message bodies may be compressed. Yet, network elements need to read the SIP headers for routing and other purposes. Consequently, there is a problem with end-to-end transmission for SIP because a network element may have to decompress headers along a route to an end point. Consequently, there may be a problem with the applicability of SigComp end-to-end as would be required as applied in SIP.
Also, in accordance with the third generation partnership project, 3G PP, for the global system for mobile communications (GSM) and which can be used in related UMTS standards, an internet protocol (IP) multimedia subsystem (IMS) has been defined for multimedia applications, for example, per TS 23.228, 24.228 and related technical specifications. There is proposed, for example, a proxy call session control function (P-CSCF), an interrogating CSCF (I-CSCF) and a serving CSCF (S-CSCF). SIP messages between one's handset and its associated P-CSCF may be compressed as are SIP messages between another person's handset and its P-CSCF. But between P-CSCF's, the SIP messages are generally uncompressed because as explained above the headers are needed for routing, and there is limited motivation to apply SigComp to a portion of a message and not the whole. These control functions are known for use in home and visited networks by mobile devices for multimedia services as an outbound proxy (the first SIP-layer point of contact for a mobile device in, for example, a general packet radio service (GPRS) network). These control functions may be accessed by a mobile device that would want to engage in a real-time interactive multimedia application with a mobile device in the same or in another wireless communication network.
The virtual machines such as the UDVM 130 of FIG. 1 are resident in, for example, a mobile device and, for example, a proxy call session control function (P-CSCF) endpoint or any other endpoint. Again, the capabilities of both ends of a communication path should be consistent with one another to successfully restore compressed content to its original form.
Presence is becoming increasingly important to wireless network features and services. Presence relates to registration of a mobile device that is turned on and in a mode for receiving communications which may be standard voice calls or limited to receiving, for example, text messages from a “buddy.” As alluded to above, one or more “buddy lists” may be input by a wireless subscriber for friends, associates and family of the subscriber and used to signal “presence” information among “buddies.” The wireless subscriber will typically wish to receive updates regarding his/her buddies' presence status, as presence status is dynamic. For example, a college student may receive presence information indicating that a given buddy is currently not available for voice calls but can receive text messages. Based on this information, the student signals that “buddy” by text message to meet him/her in the library at 10:00 AM. In so doing, eXtensible Markup Language (XML) (not visible to the user) is commonly used to represent contact information, such as an address book, each of which may be delimited with the string <contact> at the beginning of the string of contacts and </contact> at the end of the string. Inside one of the contact strings, <name> and </name> may be used to identify a name of a “buddy” or contact. Presence information, bracketed by additional delimiters, may be stored with the contact information. SIP has been identified as a suitable vehicle for publishing one's presence information and for receiving updates regarding a buddy's presence. HTTP has been identified as a suitable vehicle for managing one's buddy lists. So for presence and buddy list management, SIP and HTTP messages are launched and the message bodies may be XML documents. Consequently, there remains an opportunity to apply compression in such an application.
Referring to alternative embodiments, FIG. 2 and FIG. 2A, there is shown the format of a SigComp message which is taken from RFC 3320 FIG. 3 but modified according to an inventive aspect. A SigComp message with a “length” field equal to 00 contains an uploaded UDVM bytecode for use by the decompressing endpoint of FIG. 1. In this case, the first 12 bits after the returned feedback item indicate the length of the uploaded bytecode. Referring again to FIG. 2 or FIG. 2A, these 12 bits comprise a bytecode code_len field. RFC 3320 does not explicitly prohibit a code_len of all zeroes. However, such a code_len would not make sense in the context of loading a non-trivial bytecode. The fields remaining, except for “remaining SigComp message” are referred to in RFC 3320 as a SigComp header which may include uploaded UDVM bytecode (not shown in FIG. 2). The four bit “destination” field of FIG. 2 or 2A indicates where the uploaded bytecode may be placed.
Consequently, even with all these improvements in the art of providing compression techniques and virtual and other machines for providing compression/decompression at endpoints in accordance with alleged unlimited flexibility, there remains an opportunity to facilitate, if not to optimize, the use of compression via application, for example, of static dictionaries and other techniques for compressing various signals, bytecode, SIP and HTTP messages, XML document and other data signals used in a wireless communications network environment where the need for compression is the greatest.